Hello Thomas,

I'd like to thank you for your comments, and I apologise that it has taken
so long to catch up. We've made many changes to the draft, but there were a
few comments which we would like to reply to. Then I will summarise the
main changes we have made to the draft based on recent comments.

I will list in another email the recurring topics from your comments which
deserve discussion in the working group, and have not been fully addressed
in the current working copy of the draft.

Responses to comments:
======================
Regeneration
We use this term to refer to how we send our messages, since we send them
one hop at a time. After processing, we might then create another message
to send this information onwards to the next relevant hop, using new source
and destination IP addresses, updating the hop count, hop limit, and
metric, and may add TLVs to the message (validity time for example).
Therefore "retransmit" doesnt seem like the correct word, neither does
"forward".


P1: "offering rapid convergence in dynamic topologies"
> This is a little over-stating the applicability: these statements may be
true in some scenarios (for example, when there are few concurrent traffic
flows, and therefore few routes to repair, and therefore few flooding
operations to contend for channel access).
> As a general statement, this last sentence is incorrect.
- We could say, "in cases where the communication graph does not form a
complete graph"... or "where the number of communication flows is
relatively small"...? or "where interference is low"...?
Or borrow from AODV?:
   The Ad hoc On-Demand Distance Vector (AODV) routing protocol is
   intended for use by mobile nodes in an ad hoc network.  It offers
   quick adaptation to dynamic link conditions, low processing and
   memory overhead, low network utilization, and determines unicast
   routes to destinations within the ad hoc network.


P8 "Unreachable Address" definition
> I’d first put “Valid route” before “unreachable address”, since the
latter uses the former. [And yes, that would mean that terms would not come
in alphabetic order — I do prefer clarity over adherence to the alphabet,
though]
- It now defines Valid route before Unreachable Address, and defines
Unreachable Address as: "An address reported in an RERR message, either the
destination address of an IP packet that could not be forwarded because a
valid route to the destination is not known, or the address on a route
which became Invalid."

> Second, should “valid route” not be qualified by “to a specific address”?
- So then we would have: "Valid route: A route that can be used for
forwarding to a specific address." This would be O.K., if an address range
could be considered a "specific address".  But that seems a bit awkward.

> Third, is an “unreachable address” then not “an address to which a valid
route is not known — either because no route to that address has been
discovered yet, or because it is not possible to discover a route to that
address”.
- The current meaning of unreachable means that something is broken, not
that Route Discovery simply has not yet been attempted.  It is a useful
concept for describing RERR operation.

> By the way, I note that you distinguish “node” and “address” here; that
does mean that if a given end-point has two addresses, “IP1” and “IP2”
(possibly, on the same interface), then you will need two RREQ/RREP cycles
to discover paths to both of these?
- Yes, it does mean that.

> Also, will a remote device be able to learn that IP1 and IP2 really are
“the same device” (or even, “the same interface”)?
- Not by using AODVv2.  Moreover, for privacy reasons this is a good thing.


P9 Data Elements table definitions
> Actually, this is not really a set of “data elements” but rather the
“protocol data units” that AODVv2 routers exchange — correct? I.e., they
are defining the content of the messages, and not the data elements used by
the routing algorithm? Suggest changing the name and adding an explanation.
- Usually "PDU" means something more than what we mean by Data Element
within the draft. We do define what we mean by Data Element in the
Terminology section too.


P10 Applicability Statement
> I strongly disagree with the assertion that in emergency and disaster
relief scenarios “the ability to communicate is more important than being
assured of secure operations” — I think that that’s an unfortunate and
incorrect claim to make. I understand the complexities of providing
security of a reactive routing protocol. I believe that it would be orders
of magnitude better to call those out, and then describes the limits of
what can be done (securitywise) than to claim a set of scenarios not
needing security (especially since...they do...)
- Do you mean something more like (borrowing from our Security
Considerations section): "Using the security-related TLVs from RFC7182,
AODVv2 can be protected against replay attacks, malicious messages designed
to manipulate route decisions and divert traffic, and passive inspection of
control messages to determine topology. However, providing message
encryption is problematic due to the necessity of sharing keys."...?
> To give a simple example, given that RREQs are mutable (notably the
“metric” field) in transit, and is manipulated by all intermediaries, then
obviously a simple e2e signature (inserted using the RFC7182 format) would
require that field to be “zeroed out” for calculation/verification — which
would open an attack vector on the protocol. Calling that out, presenting
the consequences hereof, and presenting the conditions wherein — despite
that — AODVv2 would be applicable (For example, always run over a L2
providing hop-by-hop security, preventing an uninvited intruder from
overhearing and participating in the protocol), that would be particularly
valuable.
- Our security is hop-by-hop and so the above doesn't seem to apply.  We do
mention that encryption provides confidentiality.


P11 Applicability Statement - multihoming
> I think that appendix B needs to be removed. Essentially, it makes claims
that it is possible to do multi-homing — but neither specifies how it is
done, nor gives pointers to documents that justify the claim. AODVv2 does
not support multi-homing — that’s clear, and it is fine that it is called
out here. Thank you for that. Now, with that being said, I am torn between
being satisfied that it is called out on one hand, and wanting to have
“multi homing” on the other hand. RFC7181 supports multi-homing, FWIW. I
believe that this also would merit some explicit discussion by the WG, in
order to understand if this design decision is acceptable?
- AODVv2 has never explicitly supported multihoming.  Since work has been
done for the purpose of supporting multihoming, it would be useful for
people to have the benefit of that knowledge.


P11 Router Client List
> There’s no “cost”, distance, metric, associated with these attached
networks? I’d think that that’d seriously hamper some deployments..
- This is a good point. We could allow RREP_gen to initialize the cost
field to something nonzero before transmitting the RREP.  That was done in
AODV.


P11 Router Client List
> Stepping away from the “multi-homing” discussion (which we should have in
isolation) even without discussing multihoming I envision deployments where
I’d connect to “external service A” if I know that the delay is below XX —
but if it is above XXX then I’d rather connect to “external service B”…and
where the major impact on the delay could be “from the MANET router through
the external network” rather than “within the MANET”.
- Language involving "external services" is not really germane to the
operation of AODVv2.  Finding a route that obeys specified metric
constraints has been done for AODV, but was never included within the
AODVv2 specification.  It would probably be best as a separate document.


P12 Neighbor Table
> Also, is it mandatory to represent the information in the formats that
you give (in this, and other sections)? Specifically, must it be in forms
of tables? Your use of “should” here indicate that yes, if so, why?
- Now it just says "contains".  The representation is not mandatory. Would
it be better as "Neighbor Information Set"?


P13 Sequence numbers
> I would like to nit-pick that: the router can maintain this sequence
number in whatever format it pleases — but, when it includes it in control
messages, it must be representable in a specified format, respecting
certain rules.
- It is specified to be an unsigned integer. Is it better to say that it
must rollover after 65535, however it is stored? And does that affect the
statement that "This comparison MUST be done using signed 16-bit
arithmetic, in order to accomplish sequence number rollover."


P16 Invalid route
> How is this different from the information stored in the “Route Message
Table”? It would seem that the sequence number for a route is the sequence
number for the router generating the RteMsg that installed that route — and
which therefore should be in the Route Message Table? I would suggest that
it would be more “logical” to keep this information in the “Route Message
Table”, and not keep “Invalid” routes around in the Routing Set?
- The Multicast Route Message Table is used for duplicate suppression.  The
sequence number information in a route belongs the destination, not the
route. However, this is an interesting idea. Currently we update the route,
then check if the message is a duplicate to avoid regenerating it. If we
checked for duplicates first, and stored some extra info in the Route
Message Table, we might be able to avoid having Invalid routes and maybe
also Unconfirmed routes...But if we were to split the AODVv2 route set from
the forwarding table, this would be unnecessary.


P18 Default Metric Type
>I am extremely worried about pushing forth a routing protocol for MANETs,
which discusses only the “hop count metric” and which considers other
metric types exceptional — see section 5.4, which states “ Some
applications may require metric information other than hop count.” If
anything, the experiment with the Experimental MANET protocols (RFC3626,
RFC3561, …,) showed us that hop-count simply isn’t good enough. Certainly
not for wireless. Certainly not for WiFi (and its brethren).
- There are situations where hop count is in use even today in IEEE 802
Wireless. However, further discussion on metric types is suggested below.


P19 Alternate Metric Types
>Haaaaang on, does that mean that using HopCount does *not* require the
inclusion of the MetricType data element?
>If so, then I believe that this is actually a poor optimization to make:
since most (almost, all) non-trivial deployments will require non-hop-count
metrics, then they will need this element to be included.
- Yes, it does mean that, since it's the default.  If we need to make
another default, this can be changed. The default metric type can be
configured on all routers across the network to be something other than
hopcount, so that a second metric type can be made default, and while
referring to the second metric, the MetricType element does not need to be
included. Hopcount may or may not be configured for use in addition, and if
referring to the hopcount metric, the MetricType data element _would_ need
to be included.
>Do we know of an upper bound on when that might happen? Should a RREP to
that neighbor be triggered, to provoke an RREP_ACK and thus verification of
bidirectionality?
- No it should not.  Temporary disconnects should not trigger such
corrective actions.  I do not know of an upper bound.  Some protocols treat
the loss of three successive HELLO messages as a sign of disconnection.  I
don't know of any that treat loss of a single HELLO as requiring such
corrective action, at least by default.  One can usually configure the
number of HELLO messages that cause the reaction.  And similarly for ping,
etc.


P22 Message transmission - reducing multicast overhead
>A couple of very important things here. First, I note that RFC6621, afaik,
does not explicitly specify “for each received multicast message, here’s a
hook to inspect-and-modify-it (such as “update route cost”) before
retransmitting it”. Rather, it supports “flooding an identical copy of a
message to all destinations inside the MANET.
>Consequently, saying “use 6621 to reduce multicast overhead” is
insufficient: simply taking an implementation of this specification, and an
implementation of RFC6621, and sticking them together, will *not* work.
Second, this paragraph leads to noninteroperable implementations. If X
decides to implement a version using MPR-Flooding of RREQs, Y decides to
implement a version without even looking at flooding reduction, these two
might not interoperate: the flooding operation heuristics might not be
compatible to cover the complete network. Consequently, work is needed
here, to make sure that what is permitted in the specification can, indeed,
lead to independent and interoperable implementations.
- Well, we are sending single hop. Text is always appreciated.  We tried
not to go too far into this earlier, but after Last Call begins we would be
happy to craft some text or perhaps another document for this purpose.  But
the clarifying specification text will be very small, we think.
>I can easily see how non-broadcast media can have a “shim” which simulates
multicast as a sequence of broadcasts. I cannot see why that is relevant
for this specification at this point I can see that this would be
appropriate to call out in the applicability statement somewhere, that a
full broadcast L2, or a non-broadcast L2 with a L2.5-shim simulating it, is
assumed. The reason why I cannot see this (simulating multicast by way of
unicast) to be appropriate to this specification is that, as far as I have
understood it, the operations for building this L2.5-shim are not specified
(nor should they be, they’d be L2 specific).
- Not quite sure what to do about this, but if the answer is to move the
text to the applicability statement, then a cross reference should be
inserted here.
- Some further notes regarding this section: It does not suggest to use an
RFC6621 implementation alongside AODVv2. It suggests that the same
techniques described in RFC6621 could be used to determine whether the
transmission of a multicast AODVv2 message could be avoided. These
techniques could be used to acquire the information that the complete
multicast group will be covered even if the router does not regenerate a
message. A router may determine that for a received RREQ, if it decided not
to regenerate, that the RREQ will have reached enough other nodes that a
path will still be discovered. This may not result in the optimal route,
but the benefit is reduced interference.


P27 Applying Route Updates, step 2.
>Could you, similar to the clause above, add an educational text stating
“this means that ….”, please?
>Could you, similar to the first clause above, add an educational text
stating “this means that ….”, please?
- Not sure what is being requested here.  Something like, "the AdvRte is
useful"? Though this has already been determined by the process in 6.5.1.



Main changes to the draft:
==========================
* Avoided use of "node" and "subnet" where possible.
* Improved separation of data structure information from protocol operation.
* Updated uses of the terms "IP address" and "packet" to be clearer.
* More consistent and accurate use of MUST, SHOULD, SHOULD NOT, and MAY,
and added explanations of consequences of not implementing SHOULDs.
* Used consistent references to RFC 5444.
* Updated Terminology. Avoid the Data Element table. Added IAR (renamed to
ENAR - External Network Access Router). Gave clearer definition of Router
Client and Unreachable Address.
* Updated Applicability Statement description of gateway functionality and
uni-directional links. Added note about penalty for not storing persistent
state.
* Updated intro to Router Client section.
* Clarified Neighbor Table and Adjacency Monitoring sections. Only need
information on neighboring routers on discovered routes. If bidirectional
connectivity is already confirmed, requesting acknowledgement is
unnecessary. Separated Neighbor Table Updates into separate section.
* Updated Sequence Number section. Use only one sequence number per router.
Added description of sequence number comparison.
* Improved clarity of Metrics section, including initial statements on how
to handle asymmetric links, use of default metric setting, explanation of
LoopFree. Updated description of LoopFree for HopCount.
* Updated description of message prioritization near the control message
generation limit.
* Added description of backoff used for message retries.
* Improved description of how bidirectional links are handled.
* Improved text regarding creation of Unconfirmed route entries.
* Improved descriptions of route state in Data Structures section, and
processing in Route State section. Separated information on expunging
routes on memory constrained routers.
* Updated RERR description to be clearer about triggers.
* Updated IANA section to include only newly defined Messages and TLVs, and
define an Unspecified value for AddressType.

We can release these changes as draft 12 if the working group wishes to
see. However, there were a lot of comments on recurring themes which
deserve discussion by the working group to reach consensus, and which will
require a further update to the draft to incorporate. To that end, I've
summed up the recurring issues from the document in a second email, and I
invite feedback from the working group participants on how to address these.

Again, I would like to thank you and the working group for all your
comments. I am looking forward to reaching consensus and getting a new
version of the AODVv2 draft prepared.

Kind regards,
Victoria Mercieca.